Local Agent for Remote File Access System

ABSTRACT

Systems and methods for remote file access are disclosed: According to an embodiment, a local agent polls a server for a task request at a polling interval scheduled by a schedule timer in accordance with a set of local agent and remote client preferences. The local agent is responsible for executing a task from the task request and causing a file to be uploaded to the server. The local agent uses a task processor for polling a server, a schedule timer for controlling polling, and one or more protocol stacks, such as TCP/IP and SOAP, for communicating with the server. The local agent can also interface with a MAPI database for message delivery.

CROSS REFERENCE

This application is a divisional of U.S. application Ser. No.10/053,402, filed Jan. 17, 2002, currently pending, which claims thebenefit under 35 U.S.C. §119 of U.S. Provisional Application No.60/340,052, filed Nov. 1, 2001, both of which are incorporated herein byreference as if included in their entireties.

This application is related to U.S. patent application Ser. Nos.10/053,382, filed Jan. 17, 2002, now abandoned and 10/054,168, filedJan. 17, 2002, now abandoned. Both of these applications areincorporated herein by reference in their entirety.

TECHNICAL FIELD

The invention pertains to computer resource management and accesssystems, and in particular remote access to files stored in differentlocations.

BACKGROUND

An individual's home or work computer is typically used a centralrepository for information. Often, however, individuals do not work atthe same physical site, or much less with their repository computer attheir fingertips. Rather, an individual will work at one or morelocations remote from their home or work computer, and, the computerbeing the central repository for information, the user will need filesor information stored in their repository computer.

There are a number of known solutions to this problem. The most commonsolution is the use of large file servers residing on private networks,and some sort of network management software, such at Windows NT™. Insuch a system, the individual's files are stored in a large shared disksystem so that while working in a local site, a user can logon and storeand retrieve information on the shared disk, usually from a desktopcomputer at a remote site. While on the road, the individual may use alaptop computer that includes a wireless, PSTN, or LAN/WANcommunications card, such as a PCMCIA card, to “dial up” and connect tothe network and retrieve and store files.

Known software systems that are commercially available to this endinclude the Windows NT™ operating system and the Terminal ServicesClient, both by Microsoft Corp. in Redmond, Wash. Another solution isPCAnywhere™ software, available from Symantec Corp. in Cupertino, Calif.Both of these systems involve maintenance of a real-time connectionbetween the client device (needing access to the files) and the serverdevice (which is communicatively coupled to the files). U.S. Pat. No.6,131,096, by Mason Ng et al. (which requires a special downloadablepersonal information manager executable), and U.S. Pat. No. 6,131,116,by Mark D. Riggins et al. (which requires special applet informationbefore communications can be setup), both issued to Visto Corporationshows an equivalent system. Basically, these systems concern emulationof a desktop environment.

Other solutions we are aware of include WIPO publication W001/59998, byAsh Gupte et al., for Etrieve, Inc. This reference discloses a methodand system for wireless receipt of electronic messages or “e-mail”. Inthis system, e-mail messages are received by an e-mail server, wherethey are, as is usually done, stored with a unique record locator. Afterbeing saved, the e-mail server sends a notification signal to a wirelessdevice, with the unique record locator, so that a user of the wirelessdevice can initiate a “one-click” return a signal indicating that theuser wishes to receive the e-mail at the wireless device from the e-mailserver.

WIPO publication W098/49625, by Jonathan R. Engelsma et al., forMotorola, Inc., discusses a system for accessing and transferring e-mailmessages from a private computer to a multiple access wirelesscommunication system. Particular to the Engelsma et al. system is aninformation delivery agent and an internet interface. The informationdelivery agent is controlled by a server. Here, information is retrievedvia the information delivery agent, which communicates via hypertexttransfer protocol, to an internet interface and the internet interface,in turn, to the private computer. E-mail messages are converted to voicemessages, and then the voice message is automatically relayed to amobile device.

U.S. Pat. No. 6,108,711, by Christopher C. M. Beck, et al., issued toGenesys Telecommunications Laboratories, Inc., discusses a multi-mediatransaction processing system, designed to share files of various mediatypes between various layers and multiple parties to a businesstransaction by recording and extracting information from transactions,querying records, and threading records together. The Beck et al. systemappears to be targeted more toward managing interactions and work flowbetween parties than it is toward providing access to resources.

U.S. Pat. No. 6,711,611, issued to Musa Hanhan, which says it is animprovement on the Beck et al. system, discusses a proxy system wherebya worker remote from a communication center operates a workstation atthe communication center through a light client or computing device. TheHanhan system is quite similar to the Beck et al. system, but the Hanhansystem is more focused on providing full and unfettered access tohome-center data and services. To this end, Hanhan suggests that theproxy server establish and maintain a constant, real-time connection toa server or workstation at the home-center over a two-way data link, sothat software and data can be operated and accessed, then transformedand sent to the light client.

SUMMARY

We have invented systems and methods for remote file access. Thesesystems and methods include a remote file access protocol, a local agentarchitecture and methods, and remote client methods. Aspects of oursystems and methods are embodied in computer software. Features of eachof the systems and methods are set forth below in the claims.

According to an embodiment, the remote file access systems and methodsare embodied in local agent software including a plurality of softwaremodules, the software comprising a transmission controlprotocol/internet protocol stack for network communication with a serverover a network; an extensible markup language input/output parser,communicatively coupled to the transmission control/internet protocolstack, for breaking down data and commands; a simple object accessprotocol interpreter, communicatively coupled to the extensible markuplanguage input/output parser, for creating file system instructions topoll the server for a task request and retrieve a file specified in thetask request; and a task processor, communicatively coupled to thesimple object access protocol interpreter, for executing subsysteminstructions and initiating poll commands, based on a schedule timer. Inone embodiment, the local agent module can further include acommunications module configured to provide a carrier for networkcommunication to the server, the local agent module configured toperiodically connect to the server through the communication module atintervals set by the schedule timer.

In still another embodiment, the local agent module can comprise amessage application programming interface, communicatively coupled tothe task processor, for allowing access to a message applicationprotocol interface database.

According to another embodiment, the remote file access systems andmethods are embodied in a computer implemented method for a local agentcomprising the acts of: polling a server for a task request; receiving atask request from the server; executing a task from the task request;uploading a file, identified in the task request, to a server; waitingfor a schedule timer to expire; and repeating the above acts, beginningwith the act of polling.

According to one embodiment, the local agent act of executing the taskcan include initiating a request to a subsystem for the file; andreceiving the file from the subsystem. In another embodiment, the localagent act of executing the task includes: initiating a request to asubsystem for the file; instructing the subsystem to upload the file tothe server; and receiving an indication that the file was uploaded tothe server. In yet another embodiment, the local agent act of executingthe task includes: initiating a request to a message access protocolinterface for the file from a message access protocol interfacedatabase; and receiving the file from the message access protocoldatabase.

According to another embodiment, the remote file access systems andmethods are embodied in a computer implemented method for a remoteclient, comprising: sending a task request to a server, the task requestidentifying a file; receiving a notification that the task request iscomplete; and sending an instruction, responsive to the notification,concerning how to transfer the file identified in the task request.According to one embodiment, the act of sending the instructing includesidentifying another remote client to which the file is to betransferred. According to another embodiment, the method furthercomprises: polling the server for indication that the task request iscomplete; wherein receiving the act of receiving the notification isresponsive to the notification.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system drawing and a protocol according to an embodiment.

FIG. 2 shows a typical operational flow diagram.

FIG. 3 shows an exemplary software stack associated with a local agent.

FIG. 4 is a flowchart for local agent software.

FIG. 5 is a flowchart for remote client software

FIG. 6 is a flowchart for server software.

FIG. 7 depicts an exemplary database schema.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

We have invented systems and methods for remote file access comprising aserver, a remote client, and a local agent. These parts can beinterconnected via a communications network. Files needed while awayfrom a local desktop computer, on which the local agent typicallyresides, can be accessed by the remote client through a server,preferably by way of an asynchronous communication protocol.

A system architecture, a remote file access protocol, server methods, adatabase system, local agent architecture and methods, and remote clientmethods are disclosed to achieve this remote file access framework.

FIG. 1 is a system drawing which shows a typical system configuration 4and shows a communication protocol 6 according to embodiments of theinventions.

Turning first to the system configuration depicted under callout 4, webegin with a server 10. The server 10 is typically a web server and canrun on a commercially available computer, such as a Sun MicrosystemsEnterprise Server™, available from Sun Microsystems in Mountain View,Calif., or a Dell™ Gateway™ branded internet or application server. Sucha system will include one or more microprocessors, a volatile memoryarea, a persistent memory area, and one or more mass storage devices.One or more sections of computer program code, or software, either in acompiled or an interpreted form, will run, for instance, in one of thememory areas, to cause the microprocessor(s) to perform the sequences ofoperations and techniques described below.

The server 10 should include a communications software stack 12, such asan IP (internet protocol) stack, and should be able to handle hypertexttransfer protocol (HTTP) requests, secure socket layer (SSL)transactions, as well as a form of a standard generalized markuplanguage (SGML), such as extensible markup language (XML), wirelessmarkup language (WML), and optionally voice extensible markup language(VXML). Preferably, the variant of XML employed on the server isMicrosoft's SOAP™ (Simple Object Access Protocol), although Java™ or XWindows™ could alternatively be employed. Hypertextmarkup language(HTML) files are preferably included on the server 10. Thecommunications software stack 12 and the programming languages mentionedabove are generally known in the art of network communications andinterface design and are widely available.

The server 10 should further include a database management system 16,such as Microsoft Corporation's SQL Server 2000, or a version of OracleCorporation's (in Redwood Shores, Calif.) flagship Oracle™ database,running over an operating system, such as Sun's Solaris™ or Microsoft'sWindows NT™ operating system. Typically, these commercially availabledatabase systems will include connectivity software for allowing one ormore clients/users logon privileges to the database, so thatinstructions to and from the server 10 can be answered and requested,with respect to clients/users that are logged onto the server 10.

A region of memory in the server 10 is reserved for a task queue 14. Thetask queue 14 is a special purpose memory structure for storing requestsor tasks for a client/user that logs on to the server 10. These tasksand the operation of the task queue 14 will be described in furtherdetail below. We note that the task queue 14 can be an addressable partof the database 16, or it can be a specially maintained region of memoryin the server 10.

Files 48′, from the computer 44 files 48, are shown temporarily storedat the server 10. This is described in further detail below, but we notethat the files 48′ can be stored in the database 16, a special memoryregion, such as the task queue 14, or another special memory regionreserved for such files.

The server 10 is preferably configured to be communicatively coupledwith a series of clients, comprising at least a remote client 20, and alocal agent 40. Connectivity can be maintained or provided through aTCP/IP, wireless access protocol (WAP), HTTP, and/or an SSL protocol, asis depicted in the connectors between the various elements depicted inFIG. 1. Typically, the server 10 connections are maintained over anetwork 30, for instance a wide area network (WAN), such as theInternet. If a remote client 20 is to access the server 10 throughanother network, such as the public switched telephone network (PSTN),or a wireless device, then an appropriate protocol is used, and theserver 10, or an intermediary device, handles the translation from theneeded protocol and an IP protocol. In addition to connectivity featuresin the communications stack 12, communication can be made using SOAP,WML, XML or VXML, HTML programming languages.

Optionally, the server 10 can be configured to be coupled to a speechmodule 50, which is a text-to-speech and speech recognition system. Sucha system preferably implements a VXML 2.0 or higher standard, such asone of the systems offered by BeVocal, Inc., in Sunnyvale, Calif. Thespeech module 50, can be hosted on a separate server platform, or it canbe integrated into the server 10. What speech module 50 does is providea voice or tone activated series of menus for communication from client20 through the server 10, via a standard telephone or a wirelesstelephone 25.

While applying equally to telephone 25 and remote client 20, ifcommunication is maintained via a wireless carrier, then any carrier canbe used, such as the well known and widely deployed GSM or CDMA standardsystems, as well as communications using the GPRS or Bluetoothstandards. The speech module 50 is further configured to read text fromcomputer files to a listener on the telephone 25. The files are drawnfrom a memory location at the server 10, and can be in a number of fileformats, such as text, RTF, Word, WordPerfect, and HTML formats. Thespeech module 50 is configured to convert dial tone and speech from thephone 25 (remote client 20) into HTTP requests (such as POST or GET) tothe server 10.

Turning to the remote client 20, it can be a portable digital assistant(PDA), such as products offered by Palm, Inc. in Santa Clara, Calif., orequivalent devices such as those offered by Compact Computer Corp.,based in Houston, Tex., or the Blackberry™ two-way pager available fromResearch In Motion, based in Waterloo, Ontario. The remote client 20 canalso be a standard laptop computer, or a standard desktop computer.Preferably, the client 20 includes a web interface means. The interfacecan be a standard web browser, or another type of interface that allowsat least minimal connectivity between a client-server applicationimplemented in a markup language, such as HTML, FL, WML, or another SGMLvariant.

The client 20 is shown in a standard embodiment as having files 48″.These files are from server 10, copies from files 48′, and from computer44 files 48. If the speech module 50 is employed, however, then theclient 20 does not need to have files 48″ since the file 48′ contentscan be read to a user at a phone 25.

The local agent 40 is another software module that is resident on alocal computer, or the “home computer”, such as a personal desktop orwork computer—where a user's files are typically located. The localagent 40 can also be resident on a local area network (LAN) to which thelocal computer, where the files are typically located, is connected, ora local file server, such as a database system or document managementsystem, are connected. Basically, the local agent 40 must be able toachieve file access to the user's home or local files. We will describethe local agent 40 in terms of a local computer 44 for the purpose ofillustration.

As mentioned above, files 48 on a local computer 44, are accessible bythe local agent 40. he local computer 44 is typically a host system forthe software module that is the local agent 40, so the local agent 40 isinstalled and executed on the local computer 44. If the local computer44 is the host system for the local agent 40, then most of thecommunications and standard software stack that are used by the localagent 40 for connectivity and communication purposes can be found in thelocal computer 44. However, as is mentioned above, the local agent 40can be connected to the files 48 by some other physical arrangement,such as over a local area network or bus without necessarily using afull purpose computer. In such a case, the local agent 40 can includeconnectivity or communication software modules, or the local agent 40can draw upon resources of another device upon which it is installed.

Example of System Operation

Having described the system 4, we turn to FIG. 2 for an example of howthe system 4 can be operated.

In a typical setup, we envision three primary pieces of physicalhardware that comprise the system in this example. First, we have aremote client 20, which is a PDA, depicted as remote client 104. Second,we have a server 10, which is depicted and called out as ActiveRunner™server 116. Third, we have a local agent 40, resident on a home computer44, which is called out as ActiveRunner™ agent on local system 126.

A user of remote client 104 needs a file from her local system 126. At12:03 PM, she sends a task request for a particular file at act 108 tothe ActiveRunner™ server 116. The ActiveRunner™ server 116 receives thetask requests and places it in a task queue. (Previously, the userconfigured her ActiveRunner™ agent on her local system 126 to poll theActiveRunner™ server 116 every 15 minutes, beginning at 12:00 AM.)

At 12:15 PM, the ActiveRunner™ agent on the user's local system 126,contacts the ActiveRunner™ server 116 and checks to see if there are anytask requests in the queue. This is depicted as act 120. The 12:03 PMtask request is in the queue and received by the ActiveRunner™ agent.

The ActiveRunner™ agent on the local system 126 processes the taskrequest on the local system 126 at act 130. For instance, the taskrequest might have been to retrieve a contract (a Word file) that theuser was working on for a client. The Word file is returned to theActiveRunner™ agent, which in turn transfers (or “posts”) the file tothe ActiveRunner™ server 116 at act 124.

The ActiveRunner™ server 116 stores the file and associates the filewith the original task request. This association can be achieved bysetting a notification status flag and indicating a location on theActiveRunner™ server 116 where the file is located.

At act 112, the remote client 104 again polls the ActiveRunner™ server116 to see if the task request is completed. The poll causes theActiveRunner™ server 116 to retrieve the Word file stored in theActiveRunner™ server 116, so that the file is downloadable by the remoteclient 104.

We note that, in a presently preferred embodiment, the ActiveRunner™agent 126 is in charge—the agent 126 decides when and how to connect tothe server 116 and process any task requests. Thus, the agent 126 can beoperated independently of the server 116, for control purposes.

Communication Protocol for Remote File Access

Returning to FIG. 1, we now describe an inventive asynchronous remote.file access protocol 6 that is our preferred embodiment of such aprotocol used by the system 4. We describe this protocol 6 withreference to the system architecture 4, so we show dashed lines from themajor components that indicate a start or stop point for communication.We note that we do not show start or stop points with respect to thespeech module 50, but this is only for simplicity. The speech module 50is an off-the-shelf component that is integrated into our system 4primarily for data translation purposes between the server 10 and theclient 20 for situations where a remote user does not have access to adigital assistant, laptop computer, or another desktop computingdevice—rather, the user has primary access to a telephone 25.

Beginning with signal C1, the remote client 20 sends a task requestsignal to the server 10. The task request signal C1 is received by theserver 10 and is then queued in the task queue 14. The local agent 40,as part of its periodic poll of server 10, polls the server 10 withsignal A1. The signal A1 is received by the server 10, which then checksits task queue 14 for any task requests. The task request from signal C1is located, so the server 10 sends or forwards the task request to thelocal agent 40 at signal S1.

The signal S1 is received by the local agent 40 and processed. Forinstance, the local agent 40 generates a command to retrieve a localfile 48 from the computer 44, and the local file 48 is returned oridentified to the local agent 40.

At signal A2, the local agent 40 returns the task output/file to theserver 10 with signal A2. The server 10 receives the signal A2 and setsa status notification flag in the task queue 14 indicating that therequested task, from signal C1, is complete, together with a link to thefile, which is now stored on the server 10.

The server 10 can then generate a notification signal 52 to the remoteclient 20. We note that the server 10 can make a decision as to how theremote client 20 is to receive the notification of the task completesignal. It can be a “push” type of task complete signal (e.g. usingtelephone 25), or a “pull” type of task complete signal, depending onthe preferences of the user at the remote client 20.

According to one embodiment, when the notification signal S2 is receivedby the remote client 20, it is processed-by returning an instructionsignal C2 back to the server 10. The instruction signal C2 indicates tothe server 10 how the task output is to be returned to the remote client20. For instance, a file might be instructed to be directly sent, or itmight be instructed to be read, through the speech module 50, to anotherperson at particular telephone number at some location other than theuser's location.

When the instruction signal C2 is received by the server 10, it isprocessed accordingly, and the task output, here we refer to it as a“transfer”, is returned to the remote client 20 (which can again be aremote client other than the remote client 20 that initiated theoriginal task request signal C1) as file transfer signal S3.

An advantage of our communication protocol 6 is that it is asynchronous,meaning that a persistent connection between the various parts of oursystem, or even any two parts of our system, does not need to bepersistently maintained—the only exception might be where a circuitswitched call is the carrier between the remote client 20 and the speechmodule 50.

We note two other issues that we have considered. The first is securityand the second is data or file synchronization.

As for the latter, file synchronization can be achieved with a lockmanagement system implemented on the server 10. Such systems aregenerally known in the art and some typical techniques of lockmanagement are disclosed by Jim Gray and Andreas Reuter in their bookTransaction Processing: Concepts and Techniques, Morgan KaufmannPublishers, San Francisco, 1993, ISBN 1-55860-190-2, pages 406-429,which are incorporated herein by reference. As for how this fits intoour protocol 6, if an intent mode locking scheme is employed (that is,where lock modes specified according to the scope of use by the remoteagent—such as read or write), then the intended lock mode can be passedwith signal C1. This lock mode can then be sent to the local computer44, which can maintain the lock modes so that the same file is notrequested again by either the local computer 44 or the remote client 20,until the lock is released by synchronization of the file from theremote client 20.

Thus, after we receive the file and make our corrections on the remoteclient 20, we can then return the file in the same manner as we made theinitial checkout, following signals C1 and A1. At signal S1, the updatedfile would be downloaded by the local agent 40, where it would beupdated into computer 44 in files 48. The computer 44 would release thelock and send a signal back to the server 10 that the lock is released,in which case a notification signal can be returned to the remote client20. According to one embodiment, a tiered lock management system can beemployed, wherein the server 10 maintains a replication of the lockmodes in its database 16, based on the lock management information inthe local computer 44.

Turning briefly to the former, security issues, where a firewall isemployed with the files 48 on the local computer, it envisioned that thelocal agent 40 will be placed behind the firewall. Where there isconcern over an interloper receiving communications to the remote client20, a simple bit-wise barrel shifting, or more sophisticated encryptionschemes, such as public key/private key pairs, can be employed tomaintain the security of the file or information transfers. Anotheroption is to store files in a secured region of memory on the server 10using the Windows 2000™ file system.

Agent Software Architecture

FIG. 3 depicts an exemplary software architecture 140 for the localagent 40. Shown connected to the agent software 140 is the ActiveRunner™server 144, which is connected via the Internet. Also shown connected,and on which the ActiveRunner™ agent software 140 typically resides, isa local personal computer file system 172, and a local messageapplication programming interface (MAPI) database 176, from which filessuch as e-mails, a calendar, or other information can be retrieved.

The software stack depicted in FIG. 3 is shown in the order in which wehave implemented our software architecture, although other variations ofthis software stack could be implemented. We note that the drawingdepicts each module in our software stack 140 having two directionalarrows between another software module, this is to illustrate the mannerin which data flow typically passes through each module as it flowsthrough the software stack 140. Furthermore, we note that software stack140 is a logical arrangement and that installation of the local agent 40on a computer 44 can involve integrating the portions of the stack fromthe computer 44, rather than being separately installed modules—inshort: we use the resources available on the host computer to the extentpossible, where it is not possible, we install the resources as shown inthe stack 140.

First, communication with the ActiveRunner™ server 144 is achieved witha TCP/IP (transmission control protocol/internet protocol) stack. Fromthis module of the software stack, messages are parsed with an XML I/Oparser 152 into message components. From there, a SOAP interpreter 156handles the parsed messages and forwards them for actual processing to atask processor 164. For Instance, the SOAP interpreter 156 interpretsmessages to or from the task processor 164 for executing in the localcomputer subsystem, operating system, or basic input output system.(Typically, the task request from the ActiveRunner™ server 144 is a SOAPstructured request—so the other layers are primarily for handling thecarrier and packaging means for this SOAP request.)

The task processor 164 can send or retrieve files from a local PC filesystem 172, or provide functional calls into the hooks of a MAPIapplication programmer interface 168, which is used to get into data andfiles stored in a local MAPI database 176.

A schedule timer 160 is also shown. This timer is primarily forInstructing the task processor 164 to logon to the ActiveRunner™ server144 and check for task requests from the remote client 20 (FIG. 11, orto upload files or information that may not have been transferredimmediately when the local agent 40 (FIG. 1) received the task requestfrom the server 144.

Following the data flow back up through the various computer programmodules of the software stack 140: an electronic message 1 s retrievedfrom the local MAPI database 176 through the MAPI API 168. This wasreturned in reply to an inbound task request (at the local agent).

The task processor 164 prepares the electronic message into a SOAP/XMLformat and posts the file back to the ActiveRunner™ server 144, usingthe SOAP interpreter 156, then the XML 1/0 parser 152, and then theTCP/IP stack 148, where the file is finally uploaded to theActiveRunner™ server 144 over the Internet.

According to one embodiment, we have found that the Microsoft C++6, andC# development kits are ideal for development of our various modules. Aswell, the Microsoft .NET Mobile Software Development Kit works well fordeveloping web-based interfaces for the system parts.

Agent Methods

Next, we turn to FIG. 4, which is a flowchart of an embodiment of thelocal agent software 200, as implemented in the software stack 140depicted in FIG. 3.

We begin with act 204, where general preferences for the local agentsoftware are setup. For instance, the software receives preference setupinformation from a user concerning the agent polling schedule of theserver 10, access numbers (or IP addresses), and other informationconcerning establishing a connection with the server 10. Furthermore,the preferences may include file type information, whereby the usertells the local agent software security information, or remote accessprivileges—for instance, the agent software 200 can receive a list ofhard drives and folders where security is limited or restricted to thelocal computer 44 from remote clients 20, as well as public keys andprivate keys if encryption is employed.

In act 208, remote clients 20 can be setup. This can be done manually,by configuring the remote client in the agent software 200, or it can bedone automatically. What is meant here is that remote clients 20 can besetup and managed, thereby giving a user of the local agent software 200the ability to individually tailor access, security, or file transfertype information for particular remote clients, or globally setting suchpreferences, with respect to a the local computer the local agent isassociated with.

In act 212, the local agent 40 polls the server 10. This is done bylogging on to the server 10, typically using a user name and passwordpair via a modem or a LAN connection. At act 216, a test is performed todetermine whether a non-fulfilled task request exists in the task queue14 of the server 10. If a task request does not exist, then a wait stateis entered in act, 220, where the local agent 40 will logoff the server10 and then reconnect to the server 10 once the next predeterminedpolling period (setup in act 204) has expired. However, if anon-fulfilled task request exists in the task queue 14, then processingby the local agent software 200 continues to act 224.

In act 224, the task request is received, sent or downloaded from theserver 10. to the local agent 40. In act 228, the task request is parsedand executed, which typically involves retrieval of a file from thelocal computer 44, on which the local agent software 200 is typicallyresident. And at act 232, the task output is sent or uploaded to theserver 10. We note again that this act can be performed while stilllogged on to the server 10, or it can be performed after the nextpolling period has elapsed—either way, the agent software 200 returns toact 220 to wait for the next poll period to elapse.

Client Methods

FIG. 5 is a flowchart for remote client software 250. The remote clientsoftware 250 can be actively executed on the remote client 20, or it canbe an interface driven software, using XML or HTML on the remote client(thus requiring some user interaction to move to the next act)—hence theasynchronous nature of the communication protocol 6.

In act 258, preferences for the remote client are setup. This caninvolve establishing a return IP address, e-mail address, pager number,or telephone number to which task output from the local agent 40 can bereturned by the server 10. It can also involve establishing acceptablefile types (e.g. text, HTML., XML, RTF, Word™, voice, etc.), or rulesfor processing different file types (e.g., file size, file time, parsinginstructions, special segmented delivery instructions, etc.), or rulesfor processing routing information if an error occurs. The setuppreferences can also include rules for processing particular taskrequests that are uploaded to the server 10, these rules can be used fordetermining whether to proceed to acts 264 or 274 (after act 262), whichare described below.

In act 262, the remote client 20 sends a task request to the server 10.This task request is typically created as a result of the remote client40 receiving an input from a ser—usually a specific request such as “getthe email message from Jane Doe, sent Feb. 1, 2001 from my homecomputer”, entered through a web interface by a remote client.

Once the task request is sent to the server 10, the remote client 20will wait for a reply from the server 10. According to one embodiment,the remote client 20 logs off of the server 10 and the polls the server10 periodically to determine whether the task request was completed bythe local agent 40. This process is depicted in optional/alternate act254, depicted as individual acts 274, 278, and 282. However, accordingto another embodiment, remote client preferences, established with thelocal agent 40 or the remote client 20, indicate that the server 10 mustnotify the remote client 20 when the task request is complete. Thismethod is depicted a act 264, where the remote client 20 receives anotification from the server 10 that the task request from act 262 iscomplete.

At act 268, having notification that that task request is complete, arule associated with the remote client 20 is processed and instructionsfor delivery of the task output are returned by the remote client 20 tothe server 10. In act 272, the remote client 20 receives the task outputfrom the server 10, which usually involves downloading the requestedfile or information. From here, the process terminates.

Server Methods

FIG. 6 is a flowchart for the server software 300. We begin with act304, where the relational database management system 16 is setup. Here,we can setup remote client 20 and local agent 40 default values, such aspolling period for the local agent 40, file types for different remoteclient 20 types, notification messages, upload file types, and otherstandard information concerned with the file management. Preferably,pricing plans and other user information is stored in the database 16,so it can be setup too. In act 308, users are setup for the database 16.This can be via manual entry, or an automated process that is part of aHTML or XML based web interface on the server 10. We note that anexemplary database schema for the database 16 is depicted in FIG. 7 anddescribed below with reference that figure.

In act 312, a test is performed to determine whether a client 20 oragent 40 is attempting to logon to the server 10. If a client 20 islogging on, then the process continues to client processing module 320,otherwise, it continues to agent processing module 340.

In the client processing module 320, after the client 20 has logged on,then the task request is received in act 324. In act 328, the taskrequest is added to the task queue 14. And in act 332, the client 20 islogged out. Processing can continue to act 312.

In the agent processing module 340, according to one embodiment, afterthe local agent 40 has logged on, then the server 10 first determineswhether the logon is a standard poll of the server 10 to determinewhether any tasks are waiting in the task queue 14, or if the logon is afile upload. According to one embodiment, the two states are treatedIndependently of each other—meaning if you have one state, then you donot have the other. In another embodiment, the server 10 first receivesand processes the file uploaded by the agent 40, and then checks thetask queue 14 for any new tasks that need attention.

According to another embodiment, in act 344, the poll is received. Taskrequests in a task list corresponding to the local agent 20, are queriedor looked up in the task queue 14 in act 348. In act 352, a test isperformed to determine whether there are any outstanding tasks in thetask queue 14. If there are no outstanding task requests in the taskqueue 14, then the local agent 40 is informed of such and logged out(act 380). However, if there are task requests in the task queue 14,then processing continues to act 360.

In act 360, the task request is sent (using SOAP or XML syntax) to thelocal agent 40. In act 364, the completed task is received from thelocal agent 40, typically this occurs by a file download to the server10 from the local agent 40. In act 368, the server 10 can lookup anyuser preferences or special instructions to the server 10 that came withthe task request and decide how to notify the remote client 20 that thetask is complete. In some instances, a notification will be sent andinstructions received, but in other instances no notification is sent,or the instruction is setup with the initial task request.

According to one embodiment, if a notification concerning the task beingcomplete is sent to the remote client 20, then an instruction isreceived from the remote client 20 thereafter indicating to the server10 how and where to send the task output/file.

In act 372, the task output is uploaded to the remote client 20, and inact 376, the original task request, corresponding to the uploaded taskoutput, is deleted from the task queue 14. In act 380, which can takeplace anywhere after act 364, the local agent 40 is logged out of theserver 10.

Database Architecture

Turning to FIG. 7, it is a database systems schema 700 we have developedaccording to an embodiment. The database 14, which implements the schema700, as is mentioned above, can be implemented in SQL Server 2000™,which is available from Microsoft Corporation. The objective of thedatabase 16 is to provide a central repository for informationconcerning local agents 40 and remote clients 20, as well as tasks andnotifications, and the relationship of all of these entities to eachother. Of particular advantage in our schema 700 is the use specialpurpose tables as a server side cache means for storing temporary dataon the server 10 that is uploaded and in a transition state between thelocal agent 40 (more particularly a local computer 44) and the remoteclient 20.

Primary keys for each table are indicated with a key icon to the left ofthe primary key field. Keyed lines (with triangle-like shapes at oneend) between the tables show the relationship between records—e.g.one-to-many. Other lines (with parallel slashes) between particularfields in the table point out the joins between the respective fields inthe tables. According to one embodiment, not all of the joins shown, inparticular as is shown in the task and cache tables (described below),need to be maintained in the database system. The names of the fieldsare self-explanatory and can obviously change between instances of thedatabase 16 or database schema 700.

We note that three identifying properties are exhibited in the tables:First, a userid field 703 is the primarily link for a centralized set oftables, and indeed most all of the tables in the database 16. Second, acomputerID field 725 is used for identifying local agents 40 and localcomputers 44 (which are roughly equivalent, as the local agent 40resides on a local computer 44). Third, a taskID field 745 is theprimary link between the task tables. Since the userid field 703 islinked to the computerID field 725, and the computerID field 725 to thetaskID field 745, we are able to tie the local agent 40 to tasks, andthe remote client 20 to tasks—and we do this in the database 16 on theserver 10.

According to one embodiment, the task tables can include a remoteclientID to identify a remote client (that can tie back to a particular.userid 703) to the task. But for security purposes, the taskID field 745itself can be used to identify the userid, or remote clientID, orcomputerID, such as by appending values to one of the previouslymentioned values to make the taskID (and thus joining the tables throughthe prefix of the identifier).

Turning now to a detailed description of the schema: table 702 is a usertable, in it is stored information concerning particular users of. thesystem 4. Typical user information is stored in this table, such ascontact information and billing information. A pricing plan table 708holds pricing information related to the various pricing plansavailable. Invoice and payment tracking tables can also be included inthe schema 700. Also included are normalization or pull-down tables,which make data entry through an interface (such as web interface on theserver 10) consistent and user-friendly. Such a table is table 752,which speeds entry of a state. Other normalization tables can alsoexist. We also note the existence of a pre-signup table 756. This tableis for temporarily storing user information for the user table 702 priorto completing the signup task.

A set of notification tables, 716 and 720, exist to assist the server 10in completing the remote file access protocol—namely sending thenotification signal to the remote client 20 when a task is completed.These tables are joined to the user table 702 through the userid field703. Table 716 is for storing general contact information for the alert,while table 720 is for storing specific alerts responsive to completedtasks. We note that the alerts can be specified or tied to tasks, forinstance with the addition of a taskID field 745 in the notificationtables (in which case they might not be joined to the user table 702).

A set of task tables, 744, 748, 736, and 740, essentially make up thetask queue 14—although the task queue 14 can be a subset of theinformation stored in these task tables. The task queue 14 can be aseparate memory area that can be consistent addressed by the local agent40 and the remote client 20 to retrieve task information, the data inthe task queue 14 being continually updated from the task tables in thedatabase 16.

Task requests from the remote client 20 are uploaded into the taskrequest table 744. Parameters for each task are stored in one or morerecords in the task parameters tables 748, which is joined to the taskrequest table 744 through the taskID field 745. A server task table 736stores tasks that the server 10 needs to perform, which can be impartedbased on the task request table 744 (there being a one-to-manyrelationship between table 744 and 736, respectively). As was the casewith the task request table 744, a server task parameter table 740exists to store parameters for the sewer tasks in the server task table736.

Another set of tables, 712 and 704 corresponds to retrieving e-mail fromthe local computer 40. In particular, table 712 stores user informationfor retrieving the e-mail, while table 704 is a server side cache fortemporarily storing e-mail that is retrieved/downloaded by the server10. These tables are linked back to the user table 702 through theuserid field 703. According to one embodiment, an attachment table (notshown) can be joined to table 704, the attachment table being configuredto identify and store files attached to email.

Still another set of tables, 724, 728, and 732 includes local agent 40information for each of the local agents associated with a particularuser. In particular, table 724 is primary agent table that correspondsto the local agent 40 installed on a particular local computer 44. Therewill typically be one agent per computer. Tables 728 and 732, like table704, are server side cache tables, for temporarily storing browseinformation corresponding to the file system/directory and filestructure in the local computer 44 (in table 728) and files 48′ (intable 732). Their primary relation is via computerID field 725.

An example of browsing is appropriate, as it was first introduced above.Browsing is a standard task for our system 4 (while other standard tasksinclude e-mail retrieval and file transfer). A task request from theremote client 20 might be to retrieve a file 48, but the file name andlocation may not be known by the user. In this situation, the user willinstruct the remote client 20 to sent, a task request to the server 10to browse the file system of the local computer 44. The task requestwill be stored in the task tables in database 16, so that it isaccessible in the task queue 14. When the local agent 40 polls theserver 10, it will find the browse task waiting in the task queue 14,and will retrieve from the local computer 44 file structure information.This information will be uploaded from the local agent 40 into thebrowse information table 728, so that the remote client 20 can navigatethrough the folder hierarchy (this information corresponds to the files48).

The remote client 20 can then select a particular file from theinformation stored in the browse information table 728 and create a newtask request to send to the server 10. The new task request will bestored in the task tables, and the local agent 40 will poll the server10, recognizing the new task request in the task queue 14. The localagent 40 will the receive the task request from the from the server 10and process the task. The particular file will, in turn, be uploaded tothe server 10, where it will be stored in the stored file table 732.

Notification that the task is complete will be forwarded to the remoteclient 20, based on the information in the notification tables. Theremote client 20 can return instructions to the server 10 on theparticular delivery means desired for return of the task output/file.Once the task output/file has been transferred from the server 10 to theidentified remote client 20, then the data in the server side cachetables can be deleted. According to one embodiment, this data is deletedimmediately. However, according to another embodiment, data in theseserver side cache tables can “time-out”, meaning that it will stayactive and valid for a fixed expiration period. Employing a fixedexpiration time can have the advantage of improving performance andresponse time, in that, statistically speaking, once a user of a remoteclient 20 has browsed the file system on the local computer 44, there isa high likelihood that the user will again browse the file system.

According to another embodiment, the schema can further included tablefor storing information related to file synchronization and remoteclient configuration and management, as well as for task and resourcescheduling (beyond the data or information described above). Forexample, the schema can include tables. for managing an interactive modebetween the local agent and either the server and/or the remote client.

The systems and methods are described in relation to detailed figures ofparticular embodiments currently envisioned by the inventors. Thesefigures and the accompanying detailed description are intended to be forillustration, and not necessarily for purposes of limiting theinvention, except where expressly stated as such in the claims.Accordingly, alternative embodiments, in particular of the databaseschema 700, and physical or logical software structures, can beimplemented without departing from the inventive concepts disclosedabove.

Furthermore, the methods disclosed herein are intended as computerimplemented methods, to be carried out on computer readable medium, suchas a medium stored persistently in a computer, or stored and installedfrom a CD-ROM, or downloaded from the Internet. Thus, it is intendedthat the methods disclosed above and claimed below are embodied in acomputer readable medium that is computer program code or a computersoftware product configured to cause one or more processors the carryout the methods or protocols set forth in the claims. Because the designcan be modules, various means or programming modules can be included inthe computer readable medium. As such, it is not strictly necessary,unless evident in the claims, that all of the means or modules arestored in a contiguous stream of bits, but can be broken up, stored, ortaken from other programs associated with multiple microprocessors: whatmatters is that all the pieces are accessible so that the methods can beperformed.

1. A method performed by a server to provide remote access to filesrequested by a client device, the method comprising: receiving aclient-initiated request for a file, the request received by the server;entering the request in a queue of the server; receiving, from an agentdevice, a polling message requesting information from the server queue;sending the client-initiated request for a file from the queue of theserver to the agent device, wherein the agent accesses the requestedfile; receiving the requested file sent by the agent device to theserver; sending, by the server, notification to the client device thatthe received file is available; receiving, by the server, instructionsfrom the client device directing the transfer of the received file to adestination device; and transferring, from the server to the destinationdevice, the received file, wherein the agent device, the client device,the destination device, and the server are located remotely on anetwork.
 2. The method of claim 1, wherein the method step of receiving,from an agent device, a polling message requesting information from theserver queue further comprises receiving, at the server, a pollingmessage from an agent device and checking the queue for a new requestfrom one of a portable digital assistant, a two-way pager, and a laptopcomputer.
 3. The method of claim 1, wherein the method step oftransferring, from the server to the designation device, the receivedfile comprises transferring the received file from the server to one ofa client device, a speech module connected to the client device, and atelephonic device located in other than a client device location.
 4. Themethod of claim 1, further comprising: storing the request in a firstportion of a cache; and storing the received file in a second portion ofthe cache.
 5. The method of claim 4, wherein the instructions from theclient device indicates how to transfer the received file, and thereceived file is transferred from said second portion of the cache tothe remote client in response to the instruction.
 6. The method of claim4, further comprising removing the received file from the second portionof the cache.
 7. The method of claim 1, wherein the destination deviceis another client device.
 8. The method of claim 1, wherein the requestcomprises a file lock mode indicating a scope of use for the requestedfile.
 9. The method of claim 1, wherein the request comprises anindication of a file system of the agent device.
 10. The method of claim4, wherein the received file is deleted from the second portion of thecache after said transferring.
 11. The method of claim 10, wherein thereceived file is deleted from the second portion of the cache after saidtransferring upon expiration of a predetermined timeout period.
 12. Acomputer-readable storage medium containing instructions which, whenexecuted by a computer, perform a server method of providing access to afile, the method comprising: receiving a client-initiated request for afile, the request received by a server; entering the request in a queueof the server; receiving, from an agent device, a polling messagerequesting information from the server queue; sending theclient-initiated request for a file from the queue of the server to theagent device, wherein the agent accesses the requested file; receivingthe requested file sent by the agent device to the server; sending, bythe server, notification to the client device that the received file isavailable; receiving, by the server, instructions from the client devicedirecting the transfer of the received file to a destination device; andtransferring, from the server to the destination device, the receivedfile, wherein the agent device, the client device, the destinationdevice, and the server are located remotely on a network.
 13. Thecomputer-readable storage medium of claim 12, wherein the step ofreceiving, from an agent device, a polling message requestinginformation from the server queue further comprises receiving, at theserver, a polling message from an agent device and checking the queuefor a new request from the client device.
 14. The computer-readablestorage medium of claim 12, wherein the step of transferring, from theserver to the designation device, the received file comprisestransferring the received file from the server to one of a clientdevice, a speech module connected to the client device, and a telephonicdevice located in other than a client device location.
 15. Thecomputer-readable storage medium of claim 12, further comprising:storing the request in a first portion of a cache; and storing thereceived file in a second portion of the cache.
 16. Thecomputer-readable storage medium of claim 15, wherein the instructionsfrom the client device indicates how to transfer the received file, andthe received file is transferred from said second portion of the cacheto the remote client in response to the instruction.
 17. Thecomputer-readable storage medium of claim 15, further comprisingremoving the received file from the second portion of the cache.
 18. Thecomputer-readable storage medium of claim 15, wherein the destinationdevice is another client device.
 19. The computer-readable storagemedium of claim 15, wherein the request comprises a file lock modeindicating a scope of use for the requested file.
 20. Thecomputer-readable storage medium of claim 15, wherein the requestcomprises an indication of a file system of the agent device.
 21. Thecomputer-readable storage medium of claim 15, wherein the received fileis deleted from the second portion of the cache after said transferring.22. The computer-readable storage medium of claim 21, wherein thereceived file is deleted from the second portion of the cache after saidtransferring upon expiration of a predetermined timeout period.
 23. Asystem comprising at least one hardware processor and at least onememory communicatively coupled to said hardware processor, the at leastone memory having stored therein computer-executable instructions that,when executed by said hardware processor, cause the system to performsteps comprising: receiving a client-initiated request for a file, therequest received by the system; entering the request in a queue of thesystem; receiving, from an agent device, a polling message requestinginformation from the system queue; sending the client-initiated requestfor a file from the queue of the system to the agent device, wherein theagent accesses the requested file; receiving the requested file sent bythe agent device to the system; sending, by the system, notification tothe client device that the received file is available; receiving, by thesystem, instructions from the client device directing the transfer ofthe received file to a destination device; and transferring, from thesystem to the destination device, the received file, wherein the agentdevice, the client device, the destination device, and the system arelocated remotely on a network.
 24. The system of claim 23, furthercomprising a database management system that holds client information,agent information, and information relating users of the system.
 25. Thesystem of claim 23, communicatively coupled to a speech module fortranslating text from the file into speech directed to the client.